Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / networking / terms / kermit / e / v12.3 < prev next >

Wrap

Text File | 1990-08-27 | 28.9 KB | 631 lines

28-Aug-90 20:18:09-GMT,29601;000000000001 Return-Path: <cmg> Received: by watsun.cc.columbia.edu (5.59/FCB) id AA28887; Tue, 28 Aug 90 16:03:24 EDT Date: Tue, 28 Aug 90 16:03:23 EDT From: Christine M Gianone <cmg@watsun.cc.columbia.edu> To: Info-Kermit Subject: Info-Kermit Digest V12 #3 Reply-To: Info-Kermit@watsun.cc.columbia.edu Queries-To: Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU Message-Id: <CMM.0.88.651873803.cmg@watsun.cc.columbia.edu> Info-Kermit Digest Tue, 28 Aug 1990 Volume 12 : Number 3 Today's Topics: Duplicate Copies of Info-Kermit Digest V12 #1 and #2 Proposed Kermit Extension for SET FILE TYPE And ANOTHER New Test Release of MS-DOS Kermit 3.02 A New Version of Kermit for OS/2 Presentation Manager New Release UCPECAN Kermit V1.1 MS-Kermit 3.0x and German telephones Looking for Stories Digest submissions may be sent to Info-Kermit@WATSUN.CC.COLUMBIA.EDU, requests for addition to or deletion from the Info-Kermit subscriber list to Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU or to KERMIT@CUVMA.BITNET. Kermit files may be obtained over networks and by mail order. On the Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280 running UNIX (SUNOS 4.1), IP host number 128.59.39.2. Login as user anonymous (note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired files. The Kermit files are in directories kermit/a, kermit/b, kermit/c, kermit/d, and kermit/e. Test versions are in kermit/test. Binaries are in kermit/bin (use ftp in binary mode). You can also get Kermit files over the BITNET/EARN network; to get started send a message with text HELP to KERMSRV, the Kermit file server, at host CUVMA. For detailed instructions, read the file kermit/a/aanetw.hlp (AANETW.HLP on KERMSRV). To order by mail, request a complete list of Kermit versions and an order form from Kermit Distribution, Columbia University Center for Computing Activities, 612 West 115th Street, New York, NY 10025 USA. ---------------------------------------------------------------------- Date: Tue Aug 28 17:44:54 1990-EDT From: Christine M Gianone <cmg@watsun.cc.columbia.edu> Subject: Duplicate Copies of Info-Kermit Digest V12 #1 and #2 Please disregard any duplicate copies of recent Info-Kermit Digests. ------------------------------ Date: Thu Aug 16 17:44:54 1990-EDT From: Christine M Gianone <cmg@watsun.cc.columbia.edu> Subject: Proposed Kermit Extension for SET FILE TYPE Keywords: Kermit Protocol, Labeled File Type Kermit programs presently differentiate between text and binary files via the SET FILE TYPE command. When the file type is TEXT, the Kermit program that is sending the file converts the file's record format and character set from its local form to a standard form, and the receiving Kermit program converts from the standard form into its own local record format and character set. When the file type is BINARY, the file is sent as-is, byte for byte. These two ways of handling files are sufficient in many cases, but fall short when one or both computers has a complex file system, such as the Macintosh or DEC operating systems like VAX/VMS. The Kermit protocol includes a mechanism for transmitting a file's attributes in a generic way, but these attributes are of little use when the file is being received by a computer with a simple file system, such as UNIX or MS-DOS, that can't do anything with them. And they are not sufficient to convey every conceivable bit of information about about every kind of file on every kind of computer. To allow a complicated file to be transferred, a new file type is proposed: SET FILE TYPE LABELED Notice the spelling of "LABELED" (only one L between the E's). When this setting is in effect, the sending Kermit sends not only the file's data, but also system-dependent structural information about the file. Since this information can be quite lengthy, it is sent as if it were file data, in data packets preceding the actual file data, rather than in attribute packets. All of this information is sent in binary mode (no conversions). The receiver of the file can elect whether to act upon the label information, or simply store it. Kermit programs for simple file systems need no changes, and can still act as repositories for labeled files, to be sent back later to the system of origin. On the other hand, labeled file transfers between like systems (e.g. two VAX/VMS computers) will result in the reception of a file with all the correct characteristics. There are two possible modes of operation. The first (and safer) mode requires human intervention on a per-file basis, but an automatic mode is also possible. DEFINITIONS A "bare" file is a file stored on disk that does NOT contain, as part of its contents, Kermit-constructed label information. A "labeled" file is a file stored on disk whose contents include Kermit-constructed label information. FORMAT OF A LABELED FILE This description applies to a labeled file as stored on disk and to a bare file that has label information added to it by a sending Kermit. BANNER The literal text string "KERMIT LABELED FILE:", just the twenty characters within the quotes including the trailing colon, in 7-bit ASCII. ASCII is used even on non-ASCII systems (like IBM mainframes with EBCDIC). IDLEN A 2-byte ASCII decimal numeric length field, with leading zeros if necessary, for example "02". SYSID The system ID, one of the codes listed on pp.275-278 of the Kermit book. This is a string of 1 to 99 ASCII characters (but typically 1-3 characters), for example "D7" for VAX/VMS. The length of the SYSID field is given by the preceding field (IDLEN). LBLEN A 2-byte ASCII numeric length field, with leading zeros if necessary, for example "00", "02", "09", "99". LABEL A label field, 1 to 99 ASCII characters. The length is given by the preceding length field (LBLEN). The LABEL field contains the name of the file descriptor data that follows. VALEN An 8-byte ASCII numeric length field, with leading zeros if necessary, for example "00000512". Zero ("00000000") is a permissible length for a value. VALUE The value associated with the label, 0 to 99999999 bytes of information about the file in system-dependent format. The labels and the format and layout of the associated values for each system type should be clearly defined and documented. The sequence (LBLEN, LABEL, VALEN, VALUE) may be repeated for as many labeled values are needed (if VALEN is zero, then VALUE is omitted). CONTENT The file's contents, encoded in whatever form that, in combination with the labeled values, allows for its eventual reconstruction in its original form. All fields in a labeled file are subject to whatever encoding, prefixing, or compression options have been negotiated by the two Kermit programs. REQUIRED LABELS The following labels (composed of ASCII uppercase letters) are reserved, and are required in every labeled file: VERS The operating system version, e.g. "5.3-1". If there is no version to be specified, this label must still be present, but with a zero-length value. DATA This is the final label. It always has a zero-length value, which is followed immediately by the file's contents, as defined above. EXAMPLE A hypothetical example for VMS (ignore the indentation and line breaks; the length fields are marked with L's): LL LL LLLLLLLL LL LLLLLLLL KERMIT LABELED FILE:02D704VERS000000055.3-103FAB00000512<512 bytes here> 03ACL00000723<723 bytes here>02DATA00000000<file's contents here> LL LLLLLLLL LL LLLLLLLL Note: FAB and ACL are not necessarily real labels. EFFECTS ON THE KERMIT PROTOCOL When SET FILE TYPE LABELED is in effect, the sending Kermit should include the file type (") attribute, specifying a type of binary (B), if attribute packets have been negotiated. Otherwise, there is no effect on the protocol at all. In particular, a label-wise Kermit program can interoperate perfectly well with another Kermit program that is completely ignorant of labeling, in which case the latter program simply "archives" or "unarchives" the file, labels and all (provided the user remembered to place it in binary mode). This proposal does not rule out the system-independent type of file archiving, based on file attribute packets, that is described in the Kermit book. However, if the "system-dependent" attributes suggested by this proposal can be worked out in a sufficiently generic fashion, this may lead to a more effective type of transmission of complex files between unlike systems that share similar types of file characteristics (block size, record format, character set, carriage control, etc). On the other hand, for the first pass at an implementation (for VMS), it might make more sense to simply have a single system-dependent label, like "FAB", whose value is simply the File Access Block, and perhaps another one like "ACL" for its Access Control List. The two approaches do not rule each other out. USER INTERFACE When SENDING a file, the user should first determine whether it is a bare file or a labeled file. This can be done by visual inspection (looking at the first 20 bytes), or from memory (e.g. because all labeled files have a particular filetype, or are kept together in a certain directory). Then: (a) If it is a bare file, use SET FILE TYPE LABELED if you want to send label information too. (b) If it is a labeled file, use SET FILE TYPE BINARY. When receiving a file, use SET FILE TYPE LABELED if you want labels in the incoming file to be interpreted and applied, and: (a) The other Kermit is sending a bare file from a like system using SET FILE TYPE LABELED, or: (b) The other Kermit is sending a labeled file, of the receiving system's system type, from any kind of system, without SET FILE TYPE LABELED. The receiving Kermit program that has been given a SET FILE TYPE LABELED command must inspect the incoming data. The first 30-36 bytes of the first packet contain the BANNER, IDLEN, SYSID, and the first LBLEN, and LABEL (which should be "04VERS"). If these five items are in correct format, and the SYSID matches the program's own, then the program will accept the file in labeled mode. Otherwise, it will treat it as a binary file and store all the data, including BANNER, SYSID, LABELs, VALUEs, and all length fields. If a receiving Kermit program has accepted the file in labeled mode, but then encounters an unknown label or other inconsistency in the labeled file format, it must interrupt the file transfer (by putting an X in the data field of the first available ACK) and discard the file. This is because it cannot be expected to back up and undo whatever label interpretation it has already done. It is also conceivable that "similar" systems -- such as the DEC operating systems VMS and RSX-11 -- might be able to honor each other's labels. This eventuality should be allowed for, possibly with SET commands. At the discretion of the programmer, a command such as SET FILE LABEL-DETECTION { AUTOMATIC, MANUAL } could be installed. If so, the default must be MANUAL, that is, processing of labeled files occurs only if the user asks for it explicitly. For an arriving file, AUTOMATIC mode would detect the BANNER, SYSID, and first LABEL and go into action as if the user had SET FILE TYPE LABELED. When sending a file, the program would avoid adding surrounding label information if the user had already SET FILE TYPE LABELED. This sort of thing is obviously dangerous, and users should be cautioned about it. POSTPROCESSING Separate programs should be provided to translate a labeled file into a real file, to be used in case the user forgot to SET FILE TYPE LABELED, or the file was deposited by means other than Kermit. Such a program might have two options (or come in two forms): interpret the labels, and simply strip the labels. ACKS Thanks to Terry Kennedy and Frank da Cruz for suggesting this idea, and to Joe Doupnik, John Chandler, and Paul Placeway for many valuable suggestions. Comments welcome! ------------------------------ Date: Mon, 27 Aug 90 10:13:45 EDT From: Christine M. Gianone <cmg@watsun.cc.columbia.edu> Subject: And ANOTHER New Test Release of MS-DOS Kermit 3.02 Keywords: MS-DOS Kermit 3.02 >From JRD's update notes since V12 #2: 48. Add recognition of IBM PC video boards STB VGA/EM Plus (Tseng 4000) and Everex Viewpoint EV-678, from Terry Kennedy. The list of boards known to Kermit for switching between 80 and 132 columns is now: ATI EGA Wonder AT&T Everex Viewpoint EV-659, FVGA-673, EV-678, Micro Enhancer Deluxe Paradise AutoSwitch EGA Mono STB VGA/EM (Tseng TVGA) STB VGA/EM Plus (Tseng 4000), VGA/EM-16, VGA/EM-16 Plus Tseng Labs EVA board w/132-col kit installed Tseng Labs UltraPAK mono/Hercules w/132 column modes Video 7 Vega Deluxe w/ 132X25.COM driver installed and Video 7 VGA 49. Add a facility to the keyboard translator. Let key definition strings of the form {\Kverb other material} activate an existing Macro if and only if the verb is not in the list of those predefined for the keyboard translator. If "verb" matches the name of a regular Kermit Macro execute the Macro and stay on the Kermit command line; thus a CONNECT command is needed to return to Connect mode. If verb does not match a Macro then do nothing and stay in Connect mode. Be aware that searching tables for the name of the verb uses many cpu cycles and will reduce performance. Examples: DEFINE Accumlate Receive, Connect SET KEY \315 {\Kaccumulate} Pressing the IBM PC "F1" key (code \315 above) makes the keyboard translator see string {\Kaccumlate}, verb "accumlate" is not in the predefined tables, and hence Kermit invokes the Macro named ACCMULATE. That Macro puts Kermit into file receive mode and when the file, or file group, transfer has been completed it returns to Connect mode. DEFINE WP Take wp30.ini, Connect SET KEY \316 {\Kwp} This makes IBM PC key "F2" invoke macro WP which in turn reads in and executes the contents of file WP30.INI. Kermit then returns to Connect mode. Nothing happens if the user has not defined Macro WP. Braces around the whole key definition are required so that the search for the verb name is done while executing Connect mode rather than when defining the key. If the braces are omitted then only the predefined keyboard verbs are available; an error will be reported if the verb is not one of these. Text sent to the host may preceed and follow the \Kverb part. To avoid confusion "Kverb" itself, but not the "\", may be placed in braces too, such as: DEFINE Accumulate cd c:\junkmail,Receive,Connect SET KEY \315 {kermit\13\send foo.bar\13\{KAccumulate}exit\13} the pieces: |_______________________||............||_____| string to host do Macro string to host This sends the string "Kermit<carriage return>Send foo.bar<carriage ret>" to the host to invoke its Kermit and asks it to send file foo.bar. It then invokes local Macro Accumulate to receive the file, and finally it sends the string "exit<carriage return>" to the host. Braces around KAccumlate deliniate it from the final string text. There is no host command which can invoke these Macros; this protects the PC against stray garbage text and unauthorized commands from the host. Files changed are MSUIBM.asm (procedure keysv) and MSYIBM.asm. 50. Reinstate Dump screen: filename on Status display. msssho, msyibm 51. Correct a misprint in the National Replacment Character sets for Spanish. Apparently a DEC typist inserted one accent mark too many in the table. char value was is now 60h \96 accent accent just for reference 7bh \123 accent degree 7ch \124 degree n tilde 7dh \125 n tilde c cedilla 7eh \126 c cedilla tilde Corrections are in file mszibm.asm 52. Embellish the VT300 character set abilities by permitting National Replacement Character (NRC) sets to be "designated" by the host to a particular Gn set table, viz: Designator Mnemonic Description of Action ESC ( <ident> SCS Designates 94 byte character set <ident> to G0 ESC ) <ident> SCS Designates 94 byte character set <ident> to G1 ESC * <ident> SCS Designates 94 byte character set <ident> to G2 ESC + <ident> SCS Designates 94 byte character set <ident> to G3 where <ident> is: NRC country <ident> NRC country <ident> British A Italian Y Dutch 4 Norwegian/Danish ' (hex 60) or E or 6 Finnish 5 or C Portuguese %6 French R Spanish Z French Canadian 9 or Q Swedish 7 or H German K Swiss = Example: ESC ) A loads the British NRC set (A) into G1 (the ")" part). To load Latin1 into G1 use ESC - A because Latin1 is a 96 character set. NRCs are all 94 character sets. This embellishment does NOT turn on NRC operation in the Digital Equipment Corporation sense. To follow DEC usage employ SET TERM CHARACTER-SET to choose the country and have the host enable or disable NRCs by sending CSI ? 42 h or CSI ? 42 l, respectively. Changes are in file mszibm.asm. 53. Minor code corrections to parsing eight bit controls introduced by item 52. File mszibm. 54. Incorporate support for Novell's TELAPI TCP/IP Telnet program. This is selected by command SET PORT TELAPI nnn.nnn.nnn.nnn where nnn.nnn.nnn.nnn is the Internet address of the remote host, in decimal. Example: SET PORT TELAPI 129.123.1.11 (machine netlab.usu.edu) TELAPI is a component of the Novell package LAN WorkPlace for DOS. At Utah State University it was run with the Novell (ex-Excelan) EXOS 205T Ethernet board (a smart mutiprotocol board supporting TCP with NetWare IPX 802.3 style packets). Novell Utility TSU.EXE is not required. SET PORT TELAPI must not be confused with SET PORT NOVELL(NASI); they use very different communications methods. Notes on this new faciity: a) Hosts not on the local network will likely require their Internet address and the local gateway to be specified with utility ROUTE, such as ROUTE ADD 128.59.39.2 129.123.1.254 The first address is watsun.cc.columbia.edu, in New York City, and the second is that of a local gateway box (a cisco, Inc router at Utah State University in Logan, Utah). b) The communications channel is opened as an 8-bit wide BINARY character at a time mode, thus Unix hosts may require Line Feed (Control J) as a line terminator. See also item g) below regarding character \255. c) Included in this work is sending a BREAK signal as a Telnet "Interrupt Process" command. d) A status message is shown for 3 seconds if the connection cannot be established. e) Once an Internet number has been specified with SET PORT TELAPI it will be retained for subsequent SET PORT TELAPI commands. Thus it need be stated only once. SHOW COMMUNICATIONS will display the number. f) The presence of the host can be checked by sending the two bytes \255\246 which is Telnet signal "Are You There", and to which the host is supposed to send back a bell or visible message. This can be arranged easily by command SET KEY <key's ident here> \255\246 if SET TERMINAL CHARACTER-SET TRANSPARENT is selected. See TCP/IP documents RFC-854 and RFC-855 for Telnet specifications. g) Character \255 is special in Telnet; it introduces Options negotiation. To send \255 as data it must be sent twice, as \255\255 or use the new command SET SEND DOUBLE \255 to do this for Kermit packets. Please be aware of this character when sending Binary files. h) TELAPI version 3.5 sometimes has trouble hanging up a connection. It will attempt creating a new one for each new session and can exhaust its space (defaults to two of them) when an old one persists. The only cure I know is to unload the TELAPI TSR (DOS command TELAPI -u) or reboot the machine. i) TELAPI version 3.5 is also notably slow in delivering characters to terminal emulators. Expect an effective 2400 baud rate. j) TELAPI uses Interrupt 14h with high numbered function calls. Beware of using other Int 14h trapping programs simultaneously. k) Kermit uses only the Internet number form of addressing for TELAPI because the TCP "name resolver" (conversion of a name to a number) is not available directly with TELAPI. Thus, full compliance with TCP/IP specs is not available to Kermit or other external terminal emulators using the TELAPI interface. The full specs recommend using names and letting a separate group of machines, called Name Servers, provide the Internet number via TCP/IP methods. All the changes are confined to file msxibm.asm 55. Correct a real bug: if SET LOCAL ON and while in Connect mode Control- PrintScreen (copy screen to printer) are active then Kermit crashes the system. The reason is a stack overflow when the same function ends up calling itself again by roundabout means. Adequate correction required small revisions about what is or is not echoed locally. Now almost every thing except DEC status reports is echoed (my real VT320 seems to do the same). Affected files are msyibm.asm and mszibm.asm, done on 14 August. 56. Add Enviroment and command line SET COM1 and COM2 to the list as per item 4 above. 57. Significant change to \%n variables defined as macro arguments. For each Macro invocation first save variables \%0 through \%9, clear \%0..\%9, define \%0 to be the name of the macro being invoked and \%1..\%9 as the arguments to the macro. When the macro exits restore the previous \%0..\%9 variables. This process nests naturally, and ARGC still represents the one plus the number of macro arguments. C Kermit 5A and MS-DOS Kermit 3.02 are now in agreement on these items. Previously \%0 was not affected by macro invokation and \%1..\%9 were not saved and restored around the macro. The new behavior may affect scripts written in the past. File mssset.asm 58. Add alternative command syntax: SET FILE COLLISION means the same as older SET FILE WARNING and SET FILE COLLISION DISCARD is the same as SET FILE COLL NO-SUPERSEDE. Changes are in mssset.asm and msssho.asm 59. Correct problems with REM LOGIN. Is the last of problems in this area? 60. Correct problems with CTS/RTS handshake timing and half duplex. Tnx to Brian Holley for spotting them. msxibm.asm 61. Add DESQview support call to release the cpu timeslice when in Connect mode and no character is available from the serial port. msyibm.asm 62. Modify the retry procedure to send a packet character to wait 60ms rather than 10ms between each of five attempts. This may help situations where a network device may be unresponsive for about 200ms between characters. msscom.asm More changes are expected. The mstibm.boo file and the source files are in kermit/test on watsun and in the T: area of KERMSRV. The binary .EXE file is available on watsun only in kermit/bin/mstibm.exe. There is also a test 3.02 version for the DEC Rainbow, contributed by Robert Weiner of Cooper Union. It is in kermit/test/mstrb1.boo and kermit/bin/mstrb1.exe. The latest Rainbow test version tracks the non-IBM specific portions of MS-DOS Kermit, and adds some new character translations for screen dump and print screen. Thanks to Joe and Robert for their continuing work on MS-DOS Kermit! ------------------------------ Date: Mon, 27 Aug 90 14:13:12 EDT From: Christine M. Gianone <cmg@watsun.cc.columbia.edu> Subject: A New Version of Kermit for OS/2 Presentation Manager Keywords: OS/2 Presentation Manager Kermit Contributed by Brian R. Anderson of Burnaby, BC, Canada. Here is the note that accompanied Brian's submission: "The version of Kermit contained herein is for OS/2-PM. It was written from scratch by the author (Brian R. Anderson) in Stony Brook Professional Modula-2. A two part article in the September/October 1990 issues of Dr. Dobb's Journal describe this implementation (which is a port of an earlier program that I wrote for DOS in Logitech Modula-2). This program is public domain, and may be copied freely, modified/enhanced, and distributed freely (in original or enhanced form). Included on the disk are an executable version of the program (PCKERMIT.EXE); 17 Modula-2 source code files (8 .DEF and 9 .MOD); icon and resource files; make and linker response files, and the EXE definition file. To recompile the program: M2MAKE PCKERMIT <cr>. The program includes: Kermit single and multiple file transfer TVI950 Terminal Emulation (optimized for IBM7171/PROFS) Automatic renaming of files in case of name clash Continuous display of communications settings" Brian indicates that this program is the starting point for a program that will be sold commercially. Further details are in the file O2AAAA.HLP. The files are in the Kermit test area for now, pending reactions from the Kermit user community: watsun.cc.columbia.edu BITNET KERMSRV@CUVMA Comments kermit/test/o2aaaa.hlp T:O2AAAA.HLP "boo" encoding of program kermit/bin/o2aker.exe Executable program kermit/test/o2aker.boo T:O2AKER.BOO "boo" encoding of program kermit/bin/o2aker.ico Program icon kermit/test/o2aico.boo T:O2AICO.BOO "boo" encoding of icon kermit/test/o2asrc.jar T:O2ASRC.JAR Source code The boo files can be decoded into the original binary files using any of the msbpct programs available in kermit/a. The "jar" file is a text archive of the source files that can be picked apart with a text editor or a simple program. Brian's submission did not include a user manual. Many thanks to Brian for contributing this program. ------------------------------ Date: Sat, 28 Jul 90 12:10:27 PDT From: rochester!ames!claris!portal!cup.portal.com!R_Tim_Coslet@columbia.edu Subject: New Release UCPECAN Kermit V1.1 Keywords: Pecan, USCD Pascal Pecan Kermit I am submiting a minor upgrade to UCPECAN my Kermit-UCSD (Version 1.1). You should recieve 2 files: 1) a large (about 1400 lines) one containing the source (UCPUPD.PAS) and a very short one containing "installation instructions" and a brief list of changes made to V1.1 by this upgrade (UCPUPD.UPD). The changes are 1) Added a new Unit (DIR.FIXES) to work around problems encountered with SFS. This update removes Limitation #4, making BINARY file transfers exact in both SFS and AFS implementations. 2) Fixed a bug that caused an incorrect time to be sent in the attribute packet if no time was specified with the creation date (this bug affected both AFS and SFS). R. Tim Coslet Usenet: R_Tim_Coslet@cup.portal.com BIX: r.tim_coslet [Ed. - Many thanks, R. Tim! The new files have been installed in the Kermit Distribution C area. Keep up the good work!] ------------------------------ Date: Tue, 07 Aug 90 02:00:41 MEZ From: "Gisbert W.Selke" <UPP101%DBNRHRZ1@cuvmb.cc.columbia.edu> Subject: MS-Kermit 3.0x and German telephones Keywords: MS-DOS Kermit 3.0, German Here's a (partial) solution to a problem no-one besides me seems to have had: I'm running MS-DOS Kermit over a 1200 bps line in what is yet West Germany. For some obscure reason, the German PTT transmits the signal to my phone that can be used to record the fee due. (No, I never had such a gadget. Maybe some former owner of this flat had.) Unfortunately, the tone used for this is right within the range used for 1200 bps transmissions. So, if I'm lucky, I get a corrupted packet every 8 to 12 minutes (for local calls - much more often for trunk calls); if I'm in terminal mode, however, I get some 10 scrambled characters on the screen. So far, so annoying. But you ain't seen nothing yet: some of the garbage obviously contained shift-in/-out sequences, so that I was left with funny graphics characters all over the screen henceforward, where ordinary 7-bit ASCII should have been. The solution came with one of the 3.02 revisions of MS-Kermit: 'set term char ascii g1' takes care of the odd shift! Still, some of the garbage even throws me out of that; apparently, it loads a different character set into gx, where x = 1..3. So, if anyone has a way of doing away with the disturbances altogether, any help/hints/pointers will be appreciated, with software solutions muchly preferred. \Gisbert c/o <UPP101.DBNRHRZ1.BITNET> ------------------------------ Date: Mon Aug 27 10:19:29 1990 EDT From: Christine M Gianone <cmg@watsun.cc.columbia.edu> Subject: Looking for Stories ... of how Kermit has been used in imaging and visualization applications, including modelling, CAD, medical imaging, and so forth, for possible publication. MS-DOS Kermit graphics, Kermit protocol imbedded in imaging or CAD systems, whatever you know about ... ------------------------------ End of Info-Kermit Digest *************************